Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 1/csmp-v1-171.txt

Text File | 1994-12-08 | 44.5 KB | 1,204 lines | [TEXT/R*ch]

C.S.M.P. Digest             Fri, 02 Oct 92       Volume 1 : Issue 171

Today's Topics:

    Beyond List Manager
    SUMMARY:  Making an icon (was "ARGH! No icon!")
    Think C Debugger & Class dynamic typing... summary
    List of bizarre, useful keyboard combinations, version 1.1
    UNofficial description of 2 Layer Manager calls
    How to query current pixel depth?
    Think C arrays
    MoveHHi invalidates heap?
    Dragging Lines
    Can copybits _add_ the source pixmap index to the dest index?



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (Bill Stackhouse)
Subject: Beyond List Manager
Date: 4 Aug 92 23:48:25 GMT
Organization: StoneTablet Publishing

The following is a press release describing a Think C library for
programming lists with multiple variable columns/rows etc. that this
group may find of interest.

Bill

- -------------
Portland, OR -- June 17, 1992 -- StoneTablet Publishing today
introduced  StoneTable(TM) 1.0, a replacement for the Macintosh List
Manager.

Available in two versions - StoneTable and StoneTable-Limited,
StoneTable provides a rich set of functions for the Macintosh developer
who needs to display or accept data in a tabular form.
StoneTable-Limited addresses the needs of the individual developer who
may be developing personal software or shareware and has a limited
budget while StoneTable addressed the needs of the professional
developer. Programs written for use with StoneTable-Limited do not have
to be changed to use StoneTable. Conversion from the List Manager is
straight forward because StoneTable contains functions with similar
names and parameters that are semantically equivalent.

Functionality includes (* indicate features only in StoneTable):
- - variable width columns
- - variable height rows
- - data in a cell can be edited in place
- - no internal limit to the amount of data that can be stored in a cell.
    The amount of text displayed in a single cell is only limited by
    TextEdit.
- - multiple cells can be set at once
- - mouse down handling provides an optional interface for moving,
    copying, selecting, resizing a column or row plus scrolling and
    editing a cell
- - columns and rows can be hidden
- - optional lines between columns and/or rows
- - irregular selections can be made
- - columns and rows can have default titles (letters, numbers, or blank)
- - ability to scroll individual cells
- - columns can have applications supplied titles
- - *optional lines between columns and/or rows can have a user supplied
    pattern
- - *the formatting (font, size, style, first line visible) of cells can
    vary from cell to cell
- - *columns and rows can have application supplied titles
- - *ability to define a new drawing module.
- - *optional icon palette to aid in setting table mode for extended
    selections, cell edits, etc. Useful for users that limited use of
    hands and new users.
- - *define height of column title border and width of row title border
- - *sort columns and rows
- - *edit titles in place
- - *have the cursor automatically change to the proper appearance as
    it moves around the table.

System requirements:
- - System 6 or latter
- - Think C v5 (Does not use or require TCL)
- - StoneTable 40K, StoneTable-Limited 30K (approximate code size
    in program)

The package contains:
- - Think C library
- - bound Programmers Guide containing approximately 60 pages
- - sample program with source.

Pricing and ordering questions may directed to:
    StoneTablet Publishing
    Internet: [e-mail]
    Compuserve: 70303,2546

- --
[e-mail]  Public Access User --- Not affiliated with TECHbooks
Public Access UNIX and Internet at [phone] (1200/2400, N81)

---------------------------

From: [e-mail] (Jason Philip Stevens)
Subject: SUMMARY:  Making an icon (was "ARGH! No icon!")
Date: 10 Aug 92 22:49:47 GMT
Organization: Baylor College of Medicine, Houston, Tx


To all who replied to my problem, thanks.  Evidently I had a corrupted
resource;  when I deleted my resource file and rebuilt it from scratch,
all worked well.

For those who have had problems with making icons work, here are a few
tips to remember:

1) Using ResEdit 2.1 or better will be of great assistance.  Add a resource
of type 'BNDL' and it will automatically add the other needed resources.
(Thanks to Kenneth Anderson)

2) Remember to set the "Bundle Bit".  You can use ResEdit to Get Info about
the application and check it.  Note that some development environments will
set this for you automatically (THINK C) or give you the option to (MPW, or
so I am told).  (From countless submissions)

3) Make sure that the 'Creator' and 'Signature' are the same.  The signature
is set in the BNDL resource.  (From Ville Lavonius)

4) Here is a tip that I didn't understand, but may be applicable:

"Your application needs to have a valid unique ID. That is the same as the
owner resource.  If you are running system lower than 7 you could see all
owner resources in the desktop file (which you could view by resedit}.
Under system 7 it is similar but I don't know of any utilities that will
let me browse the desk top data base..."  (This from Terje Finstad)

5) A great tip that I received many times:

" ...one quick step you might try that worked for me once when
I couldn't get the damned icon to show up is take a newly formatted floppy,
i.e. you have put nothing at all on it since you formatted it; copy the
application in question to the floppy and then rebuild the desktop on the
floppy.  If the icon then shows up there, it will stay with the application
when you copy it to your hard disk."

6) From the same author (James Preston):

"...if you have the Norton Utilities, run that on a
disk containing the application.  If there is something wrong with the way
you set the bundle stuff, Norton will find it and fix it.  I've had a number
of shareware apps that showed up with the generic icon until Norton fixed
them."

7) He was also the only one to point out that there is a detailed guide in
Inside Macintosh VI, Chapter 9.

Finally, one last point.  One responder began his email with the following:

"This question comes up again and again, naturally.  Then a lot of people
takes time-sometimes much time-to help the guy out on his particular
problem- then what is the reply?  -"Now I have got it working."  Not
anything on how he got it working, nothing about the options that applies
to the different development environments, nothing about which system -
absolutely no feedback, so why should anyone then bother answering?"

In many cases, I think questions are specific enough that it would be a waste
of bandwidth to tell the whole world about a site-specific problem.  On the
other hand, if you have a problem that could be of general interest, please
summarize and repost.  It will save you and countless others from having to
help someone else with the same problem next week...

- -jps


- --
Jason Stevens            Internet:  [e-mail]
Network User Services        Voice:  [phone]
Baylor College of Medicine    Opinions expressed are mine alone.

---------------------------

From: [e-mail] (Jon Howell)
Subject: Think C Debugger & Class dynamic typing... summary
Date: 14 Aug 92 17:16:38 GMT
Organization: Tektronix

[summary]
In article <[e-mail]>, jonh@pogo (that's me!)
asked:
> When you look
> at a CObject in the Data window of the debugger, and dereference it to open
> up a view of the object's structure, it views the object as though it were
> the type it's declared as in the context. Why can't/doesn't it use the type
> the object *really* is?  For example:
>
> {
>    CView *hokey;
>
>    hokey = new CWindow;
>    hokey ->IWindow(blah blah blah);
> <> hokey ->Update();
> }
[I forgot to cast hokey above to make the method lookups work. I need a
 newsreader with a built-in precompiler. :v]
I also knew I could examine hokey in the debugger as a CWindow with:
       *(CWindow *) hokey
However, I really wish the debugger could do that on its own.
Per Mildner <[e-mail]> points out that

PM>There is a macro you can use in the debugger that tells you the class
PM>name of an object as a string. I don't remember the name but it starts
PM>with two (or possibly one) underscore. It's in the documentation
PM>somewhere.

This would come in handy when you don't know just what hokey is at the
moment, so you could look it up to do the cast.

> Another question: TC provides member() and class_name() (and another I
> forget) functions for figuring out the dynamic type of an object. I'd
> like to be able to see if an object I've been passed is of a certain
> type. However, I don't want to do a string compare (class_name), and
> member() seems to only tell me if the object is a member of class X or
> one of its ancestors.  Is there a way I can get an integer which
> uniquely identifies the class? (It'd be extra cool if it gave some info on
> the hierarchy, but... :v)
To which [e-mail] (Mark Wittenberg) responded to in the best
way -- with code! I'll include his message with a minimum of butchering
here. Thanks to you two and [e-mail] for the replies.

- ----- snip here -----
OK, there is a way.  Here are class.h and class.c that do that and more.
GetClassID does what you want, and there are several other very useful
routines as well.  You can just use Think's "__class" call directly if
that's really all that you want (I indicate "not a class" with an id
of -1 rather than Think's 0).

Note that MapClassNameToID is code largely ripped from oops.c, and this
code uses unsupported and undocumented features of v5.0.2 (translation:
I carefully studied oops.h and dug through memory a lot); I've been using
it a long and it's been very solid for me, but caveat emptor.

NewObjectByClassId is particularly nice because it's noticeably faster
than new_by_name.

/markw

- ---------------- class.h ----------------------
/*
 * Class.h
 *      - Class ID declarations
 *
 * Copyright 1991 Mark Wittenberg
 */

#pragma once

#include <CObject.h>

#define kNilClass       (-1)

typedef Str255  MAName;
typedef int             ObjClassID;

ObjClassID      GetClassID(CObject *theObject);
void            GetClassName(CObject *obj, MAName theName);
void            GetClassNameFromID(ObjClassID id, MAName theName);
ObjClassID      GetClassIDFromName(const MAName theName);
ObjClassID      MapClassNameToID(const MAName theName);
void            *NewObjectByClassId(ObjClassID currentID);

- ---------------- class.c ----------------------
/*
 * Class.c
 *      - Class ID routines
 *
 * Copyright 1991 Mark Wittenberg
 */

#define OOPS_PRIVATE
#include "Oops.h"               // change case so that <TCL Headers>
doesn't mess us up
#define INDIRECT
#ifdef INDIRECT
        #define __new __new_indirect
#else
        #define __new __new_direct
#endif

extern void *__new(...);

#if __option(far_code) || __option(far_data)
        ERROR - We assume 2-byte IDs!
#endif

#include "Class.h"

/*
 * GetClassID
 *      - Return the class id of an object.
 */
ObjClassID
GetClassID(CObject *obj)
{
        ObjClassID      id;

        id = (ObjClassID) __class(obj);
        return (id == 0) ? kNilClass : id;
} /* GetClassID */

/*
 * GetClassName
 */
void
GetClassName(CObject *obj, MAName theName)
{
        unsigned char   *name;

        theName[0] = '\0';
        name = (unsigned char *) class_name(obj);
        if( name )
                BlockMove( name, theName, name[0] + 1 );
} /* GetClassName */

/*
 * GetClassNameFromID
 */
void
GetClassNameFromID(ObjClassID id, MAName theName)
{
        unsigned char   *name;

        theName[0] = '\0';
        name = (unsigned char *) __class_name(id);
        if( name )
                BlockMove( name, theName, name[0] + 1 );
} /* GetClassNameFromID */

/*
 * GetClassIDFromName
 */
ObjClassID
GetClassIDFromName(const MAName theName)
{
        ObjClassID      id;

        id = MapClassNameToID( theName );
        return (id == 0) ? kNilClass : id;
} /* GetClassIDFromName */

/*
 * MapClassNameToID
 */
ObjClassID
MapClassNameToID(const MAName theName)
{
        struct { void *min, *max; } range;
        register void *p, *q;

        asm {

;;
;
;  establish search range
;
;;

#if __option(a4_globals)
                movea.l a4,a0
                _RecoverHandle
                _GetHandleSize
                move.l  a4,range.min
                add.l   a4,d0
                move.l  d0,range.max
#else
                move.l  CurStackBase,range.min
                move.l  a5,range.max
#endif

;;
;
;  search data area for matching name (this could probably be improved)
;
;;

                movea.l range.min,p
                movea.l theName,q
                move.w  (q)+,d1                                 ;  D1.W =
1st two bytes of name
@1              cmp.w   (p)+,d1
                beq.s   @2
                cmpa.l  range.max,p
                blo.s   @1
;
                moveq   #0,d0                                   ;  search
failed
                return
;
@2              movea.l p,a0
                movea.l q,a1
                bra.s   @4
@3              cmpm.b  (a0)+,(a1)+
                bne.s   @1                                              ;
name not found - keep looking
@4              tst.b   -1(a1)
                bne.s   @3

;;
;
;  verify we've found a class info record
;
;;

                moveq   #~1,d0
                and.w   -4(p),d0
                lea             -4(p,d0.w),a0                   ;  A0 ==>
dispatch table
                cmpa.l  range.min,a0
                blo.s   @1                                              ;
out of range - try again
                cmpa.l  range.max,a0
                bhs.s   @1                                              ;
out of range - try again
;
                moveq   #1,d0
                add.w   (a0),d0
                lsl.w   #DSHIFT,d0
                lea             ClassInfo_(name[2])+2(a0,d0.w),a1
                cmpa.l  p,a1
                bne.s   @1                                              ;
sanity check failed - try again

;;
;
; now a0 points to the dispatch table
;
;;
                move.l  a0,d0
        #ifdef BASE_REG
                sub.l   BASE_REG,d0
        #endif
                return
        }
} /* MapClassNameToID */

/*
 * NewObjectByClassId
 */
void *
NewObjectByClassId(ObjClassID id)
{
        void    *cptr;

        asm {
                move.w  id,d0
                ext.l   d0
        #ifdef BASE_REG
                add.l   BASE_REG,d0
        #endif
                move.l  d0,cptr
        }
        return __new( cptr );
} /* NewObjectByClassId */
- --

- -----------------------------------------------------------------------------
[e-mail]     Jon Howell

---------------------------

From: [e-mail] (Peter Knoppers)
Subject: List of bizarre, useful keyboard combinations, version 1.1
Organization: Delft University of Technology, Dept. of Electrical Engineering
Date: Mon, 24 Aug 1992 18:32:23 GMT

I got quite a few reactions on my posting of August 6 and I have made a few
extensions and corrections.

List of bizarre, useful keyboard combinations, version 1.1, August 24, 1992.
- -----------------------------------------------------------------------------
Effect:        Rebuild the desktop file.
How to obtain:    Hold COMMAND+OPTION during startup.
Restrictions:    None.
Why use this:    When your icons are suddenly lost, to reduce the size of the
        desktop file (and probably in some other cases).
Learned from:    Comp.sys.mac.faq, July 22, 1992.
- -----------------------------------------------------------------------------
Effect:        Don't mount the internal SCSI disk (ID=0) on startup.
How to obtain:    Hold OPTION+COMMAND+SHIFT+BACKSPACE during startup.
Restrictions:    Only on ADB keyboard.
Why use this:    To by-pass (not boot from) a corrupt internal hard disk.
Learned from:    Posting by Daniel Mueller <[e-mail]>.
- -----------------------------------------------------------------------------
Effect:        Startup with a minimal ROM-disk containing System 6.0.3,
        Finder 6.1x and AppleShare.
How to obtain:    Hold COMMAND+OPTION+X+O during startup.
Restrictions:    Only on the Mac Classic; this version of the System is NOT
        recommended to run the Classic under.
Why use this;    Don't know.
Learned from:    The Macintosh secret trick list, 16 April, 1992.
- -----------------------------------------------------------------------------
Effect:        Zap the PRAM (Parameter RAM).
How to obtain:    Hold COMMAND+OPTION+P+R during startup.
Restrictions:    Only on System 7 and your timing seems to be critical...
Why use this:    This sometimes cures weird crashes.
Learned from:    The Macintosh secret trick list, 16 April, 1992.
- -----------------------------------------------------------------------------
Effect:        Eject floppy disk before looking for a boot disk.
How to obtain:    Hold MOUSEBUTTON during startup.
Restrictions:    None.
Why use this:    If you have a boot disk in the floppy drive, but don't want
        to boot from it.
Learned from:    Michael Grabenstein <[e-mail]>
        or <[e-mail]>.
- -----------------------------------------------------------------------------
Effect:        Kill the current foreground process.
How to obtain:    Type COMMAND+OPTION+ESCAPE.
Restrictions:    Only on System 7.0.
Why use this:    After an application has crashed this might regain you
        control of the machine in order to save work done in other
        applications before restarting. Restart as soon as possible
        afterwards because some things may have been clobbered by
        the crashed application.
Learned from:    The Macintosh secret trick list, 16 April, 1992.
- -----------------------------------------------------------------------------
Effect:        Reset.
How to obtain:    Type COMMAND+CONTROL+POWER
        (power is the key with the triangle on it).
Restrictions:    Macintosh LC or Macintosh IIsi (which don't have a restart
        button).
Why use this:    To restart a hung system.
Learned from:    The Macintosh secret trick list, 16 April, 1992.
- -----------------------------------------------------------------------------
Effect:        Restart the Mac.
How To Obtain:    Type COMMAND-SHIFT-POWER.
        (power is the key with the triangle on it).
Restrictions:    Must have programmer's key installed.
Why use this:    To restart a hung system.
Learned from:    Joshua Rabinowitz <[e-mail]>.
- -----------------------------------------------------------------------------
Effect:        Interrupt; enter the debugger.
How to obtain:    Type COMMAND+POWER.
        (power is the key with the triangle on it).
Restrictions:    Macintosh LC or Macintosh IIsi (which don't have an interrupt
        button).
Why use this:    Enter the debugger (if installed, else crashes the computer).
Learned from:    The Macintosh secret trick list, 16 April, 1992.
- -----------------------------------------------------------------------------
Please MAIL additions/corrections/suggestions to [e-mail]

If there is interest, I will maintain, correct and extend this list. I expect
that the "Restrictions:" lines are not 100% correct...

I am interested in suggestions on a sorting order for these combinations. The
current order is: first all combinations that can be used during the boot
phase, then the combinations that can be used during normal operations.
Within each group the order is more or less arbitrary/accidental.
For instance: should I place COMMAND+CONTROL+POWER before or after COMMAND+
SHIFT+POWER etc. ?

- --Peter Knopprs - [e-mail]

---------------------------

From: [e-mail] (Hugues Marty)
Subject: UNofficial description of 2 Layer Manager calls
Date: 28 Aug 92 08:11:24 GMT



This post contains a header and an example of how to use some calls of
the UNDOCUMENTED (as long as I know) Layer Manager which comes along
with System 7.  Of course, this is NOT an official document, and is
here for information only. I don't have News access at the moment (I'm
sending this via e-mail), so please send mail me copies if you post
follow-ups.

PS: it only describes 2 calls of the LayerDispatch trap (0xA829).
PPS: seems to work under 7.1 beta.

- ---- C #include file following

/* Layers.h */

/* Part of the undocumented Layer Manager structures and calls
 * Information found with the help of MacsBug under MacOS 7.0.
 * Please note that using this information may make your mac
 * explode (hey, this could be a subject for a QuickTime moovie !);
 * so use at your own risks, this may break in the future,
 * etc.. (usual disclaimeer).
 * I only wish that Apple will document this manager in a very near
 * future (let's dream...).
 *
 * What I found was that a layer is associated with each running
 * applications (if it has a user-interface), which groups all
 * windows of that application. This is how you can hide an application
 * (remember 'applications' menu under system 7) and get the list of
 * other applications windows. Have fun.
 *
 * PS : If you have more information on the Layer Manager, please
 * let me know! You can join me at [e-mail]
 */

#include <PasStrs.h>

// LayerRecord is similar to a WindowRecord.
typedef WindowRecord LayerRecord;
typedef WindowPeek LayerPtr;

// This records some information on the process which owns
// the layer... Most of it is not clear (there are pointers
// to other LayerRecords, to a heap zone, etc. in the unknown
// parts)
typedef struct {
   long    unknown1;
   OSType    signature;           // The process sig.
   OSType    creator;             // The process creator
   char      unknown2[24];
   ProcessSerialNumber layerPSN;  // The process PSN
   char      unknown3[40];
   Handle    moreLayerInfo;       // This handle is 212 bytes sized.
} LayerInfo, *LayerInfoPtr;

// This function returns a pointer to the first layer record
// of the front layer on screen (front application).
// Other ones are then accessed by the GetNextLayer macro.
pascal LayerPtr GetFirstLayer(void)
    = {0x7003, 0xA829};

// This function returns a pointer to the first window record
// in the windows list of this layer.
pascal WindowPtr GetFirstLayerWindow(LayerPtr aLayer)
    = {0x7006, 0xa829};

// Some macros to access other information, and to hide and show a layer
#define GetNextLayer(aLayer) (aLayer->nextWindow)
#define GetLayerInfo(aLayer) ((LayerInfoPtr)aLayer->refCon)
#define HideLayer(aLayer) HideWindow((WindowPtr)aLayer)
#define ShowLayer(aLayer) ShowWindow((WindowPtr)aLayer)
#define ShowHideLayer(aLayer,showFlag) ShowHide((WindowPtr)aLayer, showFlag)
#define HiddenLayer(aLayer) aLayer->visible

// GetLayerName will return an address in a handle. Be aware of that.
#define GetLayerName(aLayer) \
(unsigned char *) ( (*GetLayerInfo(aLayer)->moreLayerInfo) + 0x38)


/** Some sample code to show how to put the list of layers and their
 ** windows names in a styled text with TextEdit.
 **

  TEHandle hTE;
  LayerPtr theLayer;
  Str255 name;
  TextStyle style;
  WindowPeek window;
  LayerInfoPtr info;

  hTE = TEStylNew(&windowRect, &windowRect);
  theLayer = GetFirstLayer();
  do {
    style.tsFace = bold;
    TESetStyle(doFace, &style, false, hTE);
    Pstrcpy(name, GetLayerName(theLayer));
    TEInsert(name+1, name[0], hTE);
    TEInsert("\015", 1, hTE);
    style.tsFace = 0;
    TESetStyle(doFace, &style, false, hTE);
    window = (WindowPeek) GetFirstLayerWindow(theLayer);
    while(window) {
      if (StripAddress(window->titleHandle) && StripAddress(*window->titleHandle)) {
        Pstrcpy(name, *window->titleHandle);
    TEInsert(name+1, name[0], hTE);
    TEInsert("\015", 1, hTE);
      }
      window = window->nextWindow;
    }
  } while (theLayer = GetNextLayer(theLayer));

**  The End */
- --
Hugues MARTY - ISoft, Chemin de Moulon, F-91190 Gif-sur-Yvette FRANCE
e-mail: [e-mail]

---------------------------

From: [e-mail] (Marc Berns)
Subject: How to query current pixel depth?
Date: 12 Jul 92 14:50:28 GMT

I'm a baby mac programmer with a (likely stupid) question.  Be gentle with me.

I'd like to decide whether to display a color or b&w PICT.  I do know how
(via gestalt) to check for ColorQD, but I do *not* know how to check the
pixel depth.  I can display a color PICT on a PowerBook, for example, but
it looks like s**t.  So...

What is the "right" way to ask for the pixel depth?

Thanks for any wisdom you might have for me...

- --dave jacobs (squatting on Marc Berns' account)

+++++++++++++++++++++++++++

From: [e-mail] (Michael Peirce)
Date: 12 Jul 92 18:53:41 GMT
Organization: Peirce Software


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Marc Berns) writes:
> I'm a baby mac programmer with a (likely stupid) question.  Be gentle with me.
>
> I'd like to decide whether to display a color or b&w PICT.  I do know how
> (via gestalt) to check for ColorQD, but I do *not* know how to check the
> pixel depth.  I can display a color PICT on a PowerBook, for example, but
> it looks like s**t.  So...
>
> What is the "right" way to ask for the pixel depth?

The best way to do this is by using DeviceLoop().  You pass this trap
a region you want redrawn and a drawing procedure.  It calls your
procedure repeatedly telling which bit depth your drawing to.

This has the benefit of working when you have a window that spans
monitors and each of those monitors is a different bit depth.

- --  Michael Peirce      --   [e-mail]
- --  Peirce Software     --   Suite 301, 719 Hibiscus Place
- --                      --   San Jose, California USA 95117
- --  Makers of...        --   voice: [phone] fax: [phone]
- --            SMOOTHIE  --   AppleLink: peirce & America Online: AFC Peirce

+++++++++++++++++++++++++++

From: [e-mail] (Joe Zobkiw)
Organization: The World Public Access UNIX, Brookline, MA
Date: Sun, 12 Jul 1992 23:33:31 GMT

There is a lo-mem global called ChunkyDepth that is a word. This is the current
depth of the main device. In MacsBug type "dw ChunkyDepth" for an example.

It is documented in a header file so I'm not sure if that makes it legal or
not. I'm also not sure how reliable it is but it seems to be right everytime
I've checked it.


- --
- -------------------------------------------------------------
joe zobkiw         [e-mail]        aol: aflzobkiw


+++++++++++++++++++++++++++

From: [e-mail] (Joseph Nathan Hall)
Date: Mon, 13 Jul 92 20:41:17 EDT
Organization: 5 Sigma Software


In article <[e-mail]> ([e-mail]), you write:
) I'd like to decide whether to display a color or b&w PICT.  I do know how
) (via gestalt) to check for ColorQD, but I do *not* know how to check the
) pixel depth. ...
)
) What is the "right" way to ask for the pixel depth?

What about checking the pixelSize of the window manager port?
GetCWMgrPort, etc.  Having only one monitor, I don't know what troubles
this approach has with multiple monitors of different depth...

uunet!joebloe!joseph   [phone] day   [e-mail]
v   v  sssss | Certified Guru: all-grain brewing,| 2102 Ryan's Run East
 v v  s   s  | C, synthesizer comp & arranging,  | Rt 38 & 41
  v    sss   | photography. Also not a bad cook. | Maple Shade NJ 08052
- -----My employer isn't paying for this, and my opinions are my own-----

+++++++++++++++++++++++++++

From: Sherman@128.147.155.27 (Sherman Uitzetter)
Date: 16 Jul 92 18:05:19 GMT
Organization: Pittsburgh NMRI

In article <[e-mail]> Joseph Nathan
Hall, [e-mail] writes:
>) What is the "right" way to ask for the pixel depth?
>
>What about checking the pixelSize of the window manager port?
>GetCWMgrPort, etc.  Having only one monitor, I don't know what troubles
>this approach has with multiple monitors of different depth...


  How about checking the pixelSize of the port you're going to draw
into?  Just before the DrawPicture() call, check
          (**(((CGrafPtr) thePort)->portPixMap)).pixelSize
this assumes that the current port is a CGrafPort (this should
probably be checked.)


- -Sherman.

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 16 Jul 92 20:39:43 GMT
Organization: Taligent

In article <[e-mail]>, Sherman@128.147.155.27 (Sherman Uitzetter) writes:
>
> In article <[e-mail]> Joseph Nathan
> Hall, [e-mail] writes:
> >) What is the "right" way to ask for the pixel depth?
> >
> >What about checking the pixelSize of the window manager port?
> >GetCWMgrPort, etc.  Having only one monitor, I don't know what troubles
> >this approach has with multiple monitors of different depth...
>
>
>   How about checking the pixelSize of the port you're going to draw
> into?  Just before the DrawPicture() call, check
>           (**(((CGrafPtr) thePort)->portPixMap)).pixelSize
> this assumes that the current port is a CGrafPort (this should
> probably be checked.)
>

I don't think this will work. According to Forrest The Awesome in develop #10,
the pixMap of a color window will always point to the pixMap corresponding to
the main device, even if the window is entirely on another monitor.

The thing to do is find out what device the window is on (see Technote #79 or
DTS sample code for a sample of a routine that will do this). Then check the
pixelSize field of the pixMap for that device.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.


---------------------------

From: [e-mail] (S4161006)
Subject: Think C arrays
Organization: University of Massachusetts at Amherst
Date: Thu, 16 Jul 1992 19:43:50 GMT


I want to use Think C to handle arrays of floating point numbers.  The arrays
must have a size of on the order of 8192 rows by 16 columns.  The Think C
guide says that arrays have to be less than 32K!!!  Can someone provide a
solution to this problem.  I am new to C programming on the Mac (previously
using Fortran and QuickBasic) and woudl appreciate any information.  Thanks
in advance.

Mark Normand


+++++++++++++++++++++++++++

From: [e-mail] (Joe Zobkiw)
Organization: The World Public Access UNIX, Brookline, MA
Date: Fri, 17 Jul 1992 13:14:00 GMT

You want a multiple dimensioned array, easy :)

There is no need to allocate a zillion pointers like many programmers will
tell you to do!

Allocate _one_ Pointer the size of the array. Then, you simply use a
#define macro to access it's items. For instance, a two dimensional
array and macro might look like this:

typedef struct {
    char    direction;
    char    flags;
} PointList, *PointListPtr;

#define ARRAY_ITEM(x, y, width, arrayP) (arrayP[(y*width)+x])

To access elements you might say:

PointList pl = ARRAY_ITEM(x, y, sArrayWidth, sPointsArrayPtr);

or

ARRAY_ITEM(x, y, sArrayWidth, sPointsArrayPtr) = pl;

In the above examples, sPointsArrayPtr is a ptr to the array. Each element
of the array is a PointList structure. sArrayWidth is the width of the
array. You would allocate the array like this:

sPointsArrayPtr = (PointListPtr)NewPtrClear(sArrayWidth * sArrayHeight *
          sizeof(PointList));    // allocate our ptr

Hope this helps.
- --
- -------------------------------------------------------------
joe zobkiw         [e-mail]        aol: aflzobkiw


---------------------------

From: [e-mail] (Robert C. Barris)
Subject: MoveHHi invalidates heap?
Date: 14 Jul 92 17:07:54 GMT
Organization: University of California, Irvine

In article <[e-mail]> [e-mail] (Jeffrey Verdegan) writes:
>I'm using MacsBug 6.2.2 to debug an app I'm writing in Think C 5.0, and I
>noticed some weird behavior.  Near the start of the program, I have a call to
>Debugger().  When I enter the debugger, I type hs and athc to turn on heap
>scrambling and checking.  Then, whenever my program calls MoveHHi, I get
>tossed into the debugger with the message, "The heap is invalid."
>

I've been doing a lot of this sort of thing lately. ATHC, if I remember
right, checks the heap 'on entry' to a trap and not on exit (since
that's impossible to catch in the general case).
The heap may be bad before you get to MoveHHi.

Also... traps during VBL's get HC'd too... so if the MoveHHi is executing
and a VBL or other interrupt occurs, MacsBug will try to check the heap
(if any traps are executed during the VBL/int task, of course)
and of course find that it's inconsistent (since MoveHHi is shuffling it
at the moment). So do a SC7 and see if you are actually in the middle
of the VBL handling code (it will be in the ROM, possibly a few levels up
on the calling chain). Some 'heap invalid' messages can actually be ignored.

I hope this helps.

Rob Barris
Quicksilver Software Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Mike Dodd)
Date: Wed, 15 Jul 1992 01:46:19 GMT
Organization: Apple Computer Inc.

In article <[e-mail]>, [e-mail] (Jeffrey Verdegan) writes:
>
> I'm using MacsBug 6.2.2 to debug an app I'm writing in Think C 5.0, and I
> noticed some weird behavior.  Near the start of the program, I have a call to
> Debugger().  When I enter the debugger, I type hs and athc to turn on heap
> scrambling and checking.  Then, whenever my program calls MoveHHi, I get
> tossed into the debugger with the message, "The heap is invalid."

does MacsBug break at your call to MoveHHi, or _inside_ the call to MoveHHi??
When the memory manager is munging the heap, it can be in a state where the heap
is temporarily invalid. MacsBug will catch this, even though the Memory Manager
is going to fix it up. Basically, ATHC on BlockMove and one other call (I forget
which) will tend to be called during heap compaction when the heap is temporarily
invalid...

- -Mike Dodd-
Apple Computer
** What I say is my opinion. Not Apple's. **


+++++++++++++++++++++++++++

From: [e-mail] (Jeffrey Verdegan)
Organization: U of Wisconsin-Madison College of Engineering
Date: 17 Jul 92 10:31:31 CDT

I wirte:
>> I'm using MacsBug 6.2.2 to debug an app I'm writing in Think C 5.0, and I
>> noticed some weird behavior.  Near the start of the program, I have a call to
>> Debugger().  When I enter the debugger, I type hs and athc to turn on heap
>> scrambling and checking.  Then, whenever my program calls MoveHHi, I get
>> tossed into the debugger with the message, "The heap is invalid."

Mike Dodd replies:
>
>does MacsBug break at your call to MoveHHi, or _inside_ the call to MoveHHi??
>When the memory manager is munging the heap, it can be in a state where the heap
>is temporarily invalid. MacsBug will catch this, even though the Memory Manager
>is going to fix it up. Basically, ATHC on BlockMove and one other call (I forget
>which) will tend to be called during heap compaction when the heap is temporarily
>invalid...
>
>** What I say is my opinion. Not Apple's. **

I kind of guessed (and hoped) it might be something like that, and I've gotten
one or two other responses that suggest the same thing.  I'm not sure, but I
think it's inside MoveHHi.  Everything else is resonably clean.  I know this
because I took all the calls to MoveHHi out, and ran the program for a while
with no problems, so I suspect it's just this sort of thing.

Thanks everyone for your help!
Jeff

- ----------

Jeff Verdegan
University of Wisconsin-Madison
Computer-Aided Engineering Center
[e-mail]
[phone]


---------------------------

Organization: Carnegie Mellon, Pittsburgh, PA
Date: Thu, 16 Jul 1992 14:58:32 -0400
From: Brian Campbell <[e-mail]>
Subject: Dragging Lines

    I am currently writing code (in Think C) for a graphical user
interface on the Mac.  The program is for mechanical (dynamic) system
modeling (i.e., it's a circuit simulator).  I currently have the core of
the program done... the user selects a tool (mass, spring, damper, etc)
from a tool palette, plots it down in in a grid, clicks on the icon's
handles, and makes connections.

    I am using DragGrayRgn() to drag an icon around the screen, but I
also want to drag its connecting lines along with it (so that the MOVED
icon carries its end of the connecting lines with it while the other end
remains stationary on another icon).  In an attempt to do this, I made
the last parameter of DragGrayRgn() a pointer to a function which uses
GetMouse() to continually draw a new connecting line from the moving
icon to the stationary one while continually erasing the old lines by
changing the PenPat to white.  This of course has the side effect of
also erasing any objects that are in the paths of the lines.
    Any ideas on how to drag the line while not disturbing the objects
in its path would be greatly appreciated.




******************************************************************************
Brian
[e-mail] (until 8/14)
[e-mail] (permanent)

+++++++++++++++++++++++++++

From: [e-mail] (Humayun Lari)
Date: 17 Jul 92 03:23:49 GMT
Organization: University of North Carolina, Chapel Hill

In article <[e-mail]> [e-mail] (Brian Campbell) writes:
>    I am using DragGrayRgn() to drag an icon around the screen, but I
>also want to drag its connecting lines along with it (so that the MOVED
>icon carries its end of the connecting lines with it while the other end
>remains stationary on another icon).  In an attempt to do this, I made
>the last parameter of DragGrayRgn() a pointer to a function which uses
>GetMouse() to continually draw a new connecting line from the moving
>icon to the stationary one while continually erasing the old lines by
>changing the PenPat to white.  This of course has the side effect of
>also erasing any objects that are in the paths of the lines.

One way to do this is to emulate the behaviour of DragGrayRgn in your line
drawing function. When you receive the mouseDown event, before you call
DragGrayRgn, draw the current connecting line with a pen pattern of gray and
a pen mode of patXor, and save the current location of the mouse. In your
drawing function, compare the current location of the mouse with the saved
location. If it has changed, redraw the last connecting line (again, using
gray and patXor, which will erase the line) and draw the new connecting line.

When DragGrayRgn returns, redraw the current connecting line (which will erase
it) and draw it "for real". BTW, I think DragGrayRgn uses PinRect to keep the
region within the limiting rectangle; you should do the same with the mouse
location in your drawing function.

It might be smoother to just write your own dragging function, of course, since
that gives you extra control. All you really need is a Draw function that takes
a point as its parameter, and draws the icon region and the connecting lines at
that point. Then all you have to do is track the mouse and use the above
algorithm to call Draw twice whenever the mouse moves. (E-mail if this doesn't
make sense.)


Humayun Lari
([e-mail])

---------------------------

From: [e-mail] (Thomas Busey)
Subject: Can copybits _add_ the source pixmap index to the dest index?
Organization: University of Washington
Date: Thu, 16 Jul 1992 21:46:53 GMT

For various mundane reasons, I'm trying to combine two pixmaps.  I've got the
indicies all set up so that if I can just add the index values in the pixmap
fields together, I will have a composite image that will have the properties
I want.  My problem is that I can't get copybits to just add the two index
values together.  ScrOr comes close, but no cigar.  As far as I can tell, the
Arithemetic Drawing modes work on the actual rgb color, not the index value,
and this will not work for me.

If I absolutely have to, I can add the two values with a special routine.
However, for compatiblility and speed reasons, I really don't want to do this.
Has anyone had any luck in getting copybits to add two pixmap values together
(source and dest) and place the result (in the dest pixmap)?

For those who are interested, I'm taking two 4-bit pictures (from an apple
scanner) and combining them into one 8-bit composite.  With the appropriate
choice of cluts, I can make either picture visible, and switch between the
two pictures at 60 times a second.  I can also make both pictures invisible
and still have the images on the screen.  This is ideal for use with SEGA-
3d glasses for displaying stereo images.  I'm planning on making the source
code availible to the public, so your information now will be rewarded later!

Thanks,
Tom Busey
[e-mail]
University of Washington
Seattle, WA 98195

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Fri, 17 Jul 1992 14:04:26 GMT

[e-mail] (Thomas Busey) writes:
>I'm trying to combine two pixmaps.

In a quite wacky way that nothing in the toolbox supports! :-)

>I've got the
>indicies all set up so that if I can just add the index values in the pixmap
>fields together, I will have a composite image that will have the properties
>I want.

Not quite;  I think you want to shift one index left four bits, and then
add (or 'or', it comes to the same thing).

>My problem is that I can't get copybits to just add the two index
>values together.  ScrOr comes close, but no cigar.  As far as I can tell, the
>Arithemetic Drawing modes work on the actual rgb color, not the index value,
>and this will not work for me.

Yes.  This is true.

>If I absolutely have to, I can add the two values with a special routine.
>...for compatiblility and speed reasons, I really don't want to do this.

I think you'll have to.  Compatibility isn't an issue;  as long as
you're only writing to your off-screen image, you'll be compatible.

>For those who are interested, I'm taking two 4-bit pictures (from an apple
>scanner) and combining them into one 8-bit composite.  With the appropriate
>choice of cluts, I can make either picture visible, and switch between the
>two pictures at 60 times a second.

Make a routine that combines the two 4-bit pixel images into an 8-bit
pixel image.  Call that, then CopyBits the result to the screen.

If you gotta have more speed than that, then you can write directly to
the screen and still stay compatible, but it takes a lot more effort.
Of course, if you only want to display still images in 3-D, this isn't a
problem;  the limiting factor is how fast the images change, not the 60
frames per second.

Allow me to point out that ActivatePalette() cannot be called from
within an interrupt, but that SetEntries() can.  So either (a) you do
the palette-flipping in a tight loop, and never give time to background
processes, or (b) you use the Color Manager at interrupt time, and never
share the screen with background applications.  If those 4-bit pictures
use all 16 colors, you'll need to use the Color Manager anyway, because
the Palette Manager can't change colors 0 or 255 on an 8-bit screen.
So you're not going to be Mr. Compatibility anyway;  you may as well
grit your teeth and dig in.  :-)
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 I'm having a lot of trouble seeing how a request that you "shut up" can be
 interpreted as "looking to other people for validation."      - Tim Pierce

---------------------------

End of C.S.M.P. Digest
**********************